The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Networks have become an important tool for businesses and consumers alike, many of which are now dependent on the constant availability of network resources such as mail servers, Web sites, and content servers. As use of networks increases, protecting networks from disruption by malicious entities through denial of service (“DoS”) attacks becomes more critical. DoS attacks deprive legitimate users of access to network services, and have been used successfully to disrupt legitimate user access to internet sites such as Yahoo! and CNN.
One type of DoS attack takes advantage of the basic design of the Transmission Control Protocol (“TCP”), one of the foundational protocols of the Internet, as defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 793. This type of DoS attack, known as a TCP Reset or RST attack, exploits the fact that under an implementation of TCP that is compliant with RFC 793 a TCP connection can be properly terminated in response to receiving a TCP packet from a remote node in which the Reset bit (“RST bit”) in the header is set.
A TCP Reset attack seeks to shut down legitimate TCP sessions by injecting, into an active TCP connection, a spoofed segment with the Reset (RST) flag set and containing a packet sequence value that falls within a range of valid sequence values as allowed by the receiving node. Typically an attacker first determines or guesses the IP addresses of both endpoints and the port numbers that the endpoints are using for a TCP connection or higher-level protocol. A successful attacker also guesses a sequence number that falls within the allowed range or window. Sending any TCP segment with the RST flag set, correct IP addresses and port numbers with the sequence number falling within the window of the TCP connection can cause a receiving node that implements TCP properly under RFC 793 to shut down the TCP connection.
A TCP SYN attack proceeds in a similar manner. If an attacker sends a TCP packet with the SYN bit set in the header, and a sequence value that falls within a window of allowed sequence values, under RFC 793 the receiving node closes the TCP connection and sends a TCP RST packet. RFC 793 provided this process in order to enable non-synchronized hosts to close a connection and re-synchronize, but in contemporary practice the process creates a security vulnerability.
Border Gateway Protocol (BGP), Label Distribution Protocol (LDP), Multicast Source Discovery Protocol (MSDP), Hypertext Transfer Protocol (HTTP), some voice protocols, Multi-Protocol Label Switching (MPLS), and other protocols use TCP connections and are targets for these attacks. The consequences can be severe. For example, when a BGP session of a router is disrupted by closing the associated TCP connection, the router will discard all BGP routes that it has created, essentially causing a failure of the BGP process. As a result, the BGP process must re-synchronize itself with peer routers in the network, and during the re-synchronization period the failed router cannot forward any traffic. Accordingly, researchers in this field are interested in creating ways to thwart TCP Reset attacks, without fundamentally altering the operation of TCP as specified in RFC 793.
In one approach, researchers have thought that by assigning a pseudo-random 32-bit value as the Initial Sequence Number (ISN) for a new TCP connection, an attacker could not guess the correct sequence number in any practical way, because the number of potentially correct values is 232 or approximately 4 billion values, making such an attack virtually impossible. This principle may be true in the case of an attacker who attempts to inject a data segment into an existing TCP connection.
However, a conventional TCP implementation compliant with RFC 793 will accept a RST segment or SYN packet if the sequence number of the segment falls within a window or range of acceptable values, even if the sequence number is not an exact match to the next expected sequence number. This approach is used to compensate for the possibility that packets may be lost. In some implementations of TCP the range of allowed sequence values may be as large as 16,000 to more than 50,000 values. Unfortunately, a consequence is that the attacker does not need to generate all 32 bits of the sequence number correctly to provide a number that a receiving node will accept, even when a truly random or pseudorandom ISN is used. If the range of allowed sequence values is sufficiently large, then the chance is greatly increased that an attacker can guess a correct sequence value through either random or brute-force selection in a practical amount of time. The larger the window established by the receiving node, the easier it is for the hacker to carry out this attack.
Thus, a TCP implementation that merely checks a newly arrived RST packet or SYN packet for an established connection to determine whether the sequence number is within a given window, and tears down the connection if so, is inadequate to prevent attack by a hacker seeking to terminate a connection prematurely.
Another approach, as used in the OpenBSD implementation of TCP under UNIX, guards against a Reset attack by requiring that the Reset packet carry a sequence number that is exactly the next expected sequence number, and not just within the expected window. If a Reset packet carries a sequence number that is not an exact match, the TCP process ignores the Reset packet and does nothing. However, this approach is considered impractical, because for a receiver more often than not the sequence number of a TCP packet is not the same as the next expected due to loss of packets. When lost packets occur in the OpenBSD approach, the receiving node is left with a connection that the sending node considers closed.
In still another approach, TCP RST “damping” is performed in which a node ignores RST packets if too many such packets arrive within a given time period. However, this approach is inadequate because even one improper RST packet may be sufficient to induce closure of a critical TCP connection.
An approach for addressing a similar attack, known as the SYN-RST attack, is provided in co-pending application Ser. No. 10/641,494, filed Aug. 14, 2003, entitled “Detecting network denial of service attacks,” of Pritam Shah et al., and assigned to the same assignee hereof. The approach of Shah et al. is appropriate for an intermediate router rather than a TCP endpoint device, but does not fully address all issues described in this disclosure.
Another approach is described in co-pending application Ser. No. 10/755,146, filed Jan. 9, 2004, entitled “Preventing Network Reset Denial of Service Attacks,” of Mitesh Dalal et al., and assigned to the same assignee hereof. The approach of Dalal et al. incurs one additional round-trip packet exchange to implement a challenge and response, and also injects additional segments into the network, increasing the use of valuable bandwidth. Although the approach of Dalal et al. is highly useful, an attacker can succeed by guessing correct values for the 4-tuple of values that identifies the TCP endpoints, and a 32-bit sequence number matching the “rcvnxt” value maintained in the Transmission Control Block (TCB). Thus, a solution having additional robustness against attack would be useful to have.
Researchers at Cisco Systems, Inc. have proposed certain ways to address malicious BGP session resets at the TCP level, in the IETF internet-draft document entitled “draft-ietf-tcpm-tcpsecure-01.txt.” While the approach of this draft is beneficial, additional improvements could be made. For example, TCP cannot originate data on behalf of an application for retransmission until an acknowledgment is received from a peer network element. Further, a TCP-based solution needs to be deployed in all network elements before it becomes effective, and there is no test to ensure that all routers are using the solution. Therefore, a BGP process cannot rely solely on TCP to prevent attacks that cause a BGP connection reset.